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COMPUTER SERVICES FOR SMALL SITES 


Most medium and large size organizations use computers 
today, some of them in very sophisticated ways. Further, a good 
number of these organizations have gone through a period of con- 
solidation and centralization of computer facilities, to reduce 
costs and standardize services. So it isa matter of some concern to 


them that small, often remote, organization units of these bigger - 


enterprises are beginning to ask for their own in-house computer 
services. These units are subsidiary companies, regional offices, 
warehouses, feeder production plants, and the like; they have 
many of the characteristics of small, stand-alone businesses. The 
question is: how best to provide computer services to these sites— 
via corporate in-house networks, via commercial time sharing 
services, via service bureaus, or via the new small business com- 
puters. Corporate offices often feel that requests for any of the last 
three of these represent a loss of control and a step backward in 
time. We have talked to people at a number of small sites, to get 
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their side of the story. Here is what we found. 


Chea of data processing has been the 
main trend during the past ten to fifteen years. 
The typical medium or large organization has one 
or two major computer centers that provide most 
of the data processing services for the units of that 
organization. Further, these centers receive the 
bulk of the attention in the plans, reports, and 
discussions of data processing services within the 
organization. 

But such an organization might have, say, 15 
small, widely dispersed operating units, with an 
average of 10 to 15 employees each. Each of these 
operating units functions very much like a small 
business; corporate headquarters provides finan- 
cial control, in the main. Further, these units may 
not be in large cities and nor are they near their 
corporate data processing centers. None of them 
is large enough to justify a data processing “‘staff” 
such as a programmer, system analyst, or full-time 
computer operator. However, each of them 
wants a series of financial and management con- 
trol services that the two data processing centers 
are not in a position to provide. 


How best can the desired services be provided 
to these units? 

Or consider another not-unusual case of the 
large corporation that, in addition to its main pro- 
duction facilities, has several widely scattered 
production plants employing from 100 to 500 
people each. The production control require- 
ments at each of these smaller plants are reason- 
ably complex but are somewhat different in 
nature from production requirements in the ma- 
jor plants. Existing production control appli- 
cation programs won't do the job. Because of the 
heavy load of batch work at its data processing 
centers, the company is reluctant to develop fast 
response production control systems, using re- 
mote terminals, for each of these plants. 

How can these plants best get their desired pro- 
duction control systems? 

The problem of providing data processing serv- 
ices for situations such as these is complicated by 
several factors: (a) the small size of the units, rang- 
ing from, say, 10 to perhaps 500 employees; (b) 
the “unique” requirements at each site, such that 
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the company’s existing application programs are 
not suitable for any of the small sites as is; (c) fre- 
quently, these units are located at rather remote 
points; and (d) the small size of the units means 
that they cannot justify a data processing staff, for 
either development or operations. 


Some alternative solutions 


Here are some of the ways that data processing 
services are being provided to small remote sites, 
along with some of the advantages and short- 
comings of each. Note that these advantages and 
shortcomings do not always hold but we gather 
that they happen more frequently than not. 

Company in-house network. If the corporate 
data processing center(s) provide the desired serv- 
ices, corporate control of programs and data is re- 
tained. Economy of scale may occur. On the 
negative side, the small units usually have a low 
priority for development and enhancement re- 
sources. The corporate centers favor high volume 
users; the small users require a proportionally 
higher share of attention and help than their 
workload justifies. Further, the costs of data com- 
munication and terminals are non-trivial, perhaps 
approaching the cost of in-house small 
computers. 

Batch service bureaus. The advantages and 
shortcomings of batch service bureaus are well 
known. Batch processing is usually more econom- 
ical than fast response processing. Application 
packages may already be available from the bu- 
reau, eliminating large development costs. How- 
ever, batch processing implies delays, file 
printouts are needed for handling queries, and the 
delivery of input to the bureau and output from 
the bureau can be troublesome or even 
unreliable. 

Commercial time sharing services. As compared 
with an in-house network, the commercial time 
sharing service (Tss) is more likely to have gener- 
alized application packages available. The Tss 
might be better set up for serving remote sites, ei- 
ther by its own network or by networks such as 
Telenet and Tymnet. The rss might provide de- 
velopment and enhancement for the small site 
more readily than would the corporate center. On 
the negative side, the programs and data for the 
application packages probably will not be com- 
patible with corporate standards. The packages 
may offer so many options (“goodies’’) that costs 
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can rise quickly, well above the original 
estimates. 

Small business computers. We are talking here 
about complete, small systems—say, 32 kbytes of 
memory, one or more disk or diskette storage 
units, one or more CRT terminals, and a line 
printer or high speed character printer. These 
units provide on-line query capability, immediate 
updating capability, and can be operated almost 
like a piece of office equipment. Local manage- 
ment has full responsibility for getting the data 
processing work done. On the negative side, the 
processing costs may be somewhat higher than for 
comparable work on a large central computer. 
Corporate control of programs and data is dimin- 
ished. These systems may encourage “‘the return 
to 1401 days,” in the words of one pp manager. 
And, of course, there is the problem of getting the 
application programs developed and maintained 
for these systems. 

In our study of computer services for the small 
sites, we concentrated on the last two of these so- 
lutions. We searched out successful cases, for two 
reasons. For one thing, if these solutions do be- 
come widely tised, it will be because of the suc- 
cessful cases. Secondly, we have found that there 
are just too many variables present to explain the 
unsuccessful cases. Even with the successful cases, 
though, we intended to learn about the problems 
encountered. We tried to select cases both in 
large cities and in remote, almost rural, locations. 
And we sought out users that had adopted differ- 
ent approaches for getting their applications pro- 
gramming done. To find this variety, we ended up 
talking to both smaller units of large organiza- 
tions as well as some small, stand-alone businesses. 

A key point to keep in mind while reading the 
following case examples is this: most of the com- 
panies we talked to had no programming capabil- 
ity and none really wanted this capability. In one 
or two cases, the company felt that it would be 
forced to develop this capability. But most had 
decided to buy any needed programming services 
from outside. 

How do these companies get their application 
programs? There were two main sources: 

e Use generalized application packages 

¢ Use outside programming services 

We will discuss the case examples in the 
context of how the application programs were 


- obtained. 


Generalized application packages 


In our January 1977 issue, we discussed the sub- 
ject of in-house development of common systems 
by The Coca-Cola Company, the Eastman Kodak 
Company, and Shell Scandinavia. These common 
systems were application programs designed to 
meet the needs of a number of similar subsidiary 
companies operating in different countries. Even 
though each subsidiary company might feel that 
“our needs are different,” the packages could in 
fact be installed in subsidiary after subsidiary with 
essentially no change. 

It is apparently quite difficult and expensive to 
develop truly generalized application packages, 
as compared with the effort to develop an appli- 
cation system for one particular company. If the 
package is to meet the needs of 3 or 4 users, then 
the added cost may be in the order of 10% to 15%. 
But if the package is to serve tens or hundreds of 
users, even subsidiaries within the same company, 
then the development costs may be at least two to 
three times as great as for a one-site system. 

Historically, so-called “‘packaged”’ application 
systems have been developed to meet the needs of 
one particular user. If a supplier participated in 
the development, the supplier may have decided 
to try to sell the system to some other user. Typi- 
cally, the package—if appropriate at all—had to 
be modified to meet the needs of the second user. 
The same thing occurred with a third user. But it 
was not unusual for a user to find so many changes 
required that it was more economical to start 
from scratch rather than to try to modify the 
package. 

In our January 1977 issue, we discussed the phi- 
losophy of true generalized design—not the “cut 
and fit” approach just described. In generalized 
design, the needs of the whole population of pros- 
pective users are determined at the outset. The 
system is designed to meet all of those needs. This 
is done by identifying the true variable factors (as 
differentiated from “personal preference’ vari- 
ations) and then finding efficient ways to accom- 
modate those variables. This process has not yet 
been widely practiced. 

But there are some truly generalized appli- 
cation systems now being offered. We will begin 
our discussion with IBM’s Industry Application 
Programs (1APs), designed to run on the System 
32. 
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IBM’s IAPs 


IBM has tried many approaches for providing 
customers with application software. One of the 
more recent is the rap approach, so far offered 
only with the System 32. We were impressed with 
how easily 1aps were installed in a number of 
companies. We talked to several users in central 
Wisconsin, for instance, about 100 miles north of 
Madison, as representative of sites that are re- 
mote from major cities. 

Consoweld Corporation, located in Wisconsin 
Rapids, Wisconsin, is a subsidiary of the Consoli- 
dated Papers, Inc. The parent company has an- 
nual sales of about $300 million; Consoweld, 
which employs about 350 people, has sales of 
some $20 million per year. Consoweld manufac- 
tures decorative laminated plastic for counter 
tops, furniture, and so on. 

In mid-1975, Consoweld decided to replace 
their IBM System 3/10 with a System 3/8 and a 
System 32. The two computers would give them 
more flexibility at a slight increase in cost. At the 
same time, they decided to install portions of the 
construction management accounting system IAP 
for the first applications on the System 32. 

The first application for the 32 was an accounts 
payable system that was being handled on a me- 
chanical posting machine. The System 32 with 
the rap programs arrived in late October, and par- 
allel processing was done during November. Cut- 
over to the new system occurred on December I. 

This conversion occurred as the year-end peak 
load was building up. So the people at Consoweld 
found it difficult to study the IBM installation 
guide as thoroughly as they would have liked. The 
few difficulties they experienced with the in- 
stallation would have been largely avoided if they 
had been able to follow the guide, they told us. 
The IBM systems engineer was very helpful in 
getting the conversion to go as smoothly as it did. 

The next package used was the general ledger 
package. It was installed in early 1976. Parallel 
operation occurred in March, with cutover in 
April. The package worked correctly but some 
manual adjustments were needed for some ac- 
count balances. Gradually the manual system for 
providing input to the package was smoothed out _ 
so that by the end of summer the output reports 
were the final general ledger statements. 

Consoweld did find a few minor flaws or short- 


comings in the packages, none of which held up 
their use of the packages. No custom program- 
ming was required to adapt either package to 
their needs. Two flaws were reported to IBM and 
may be corrected in subsequent releases of the 
packages. 

Consoweld expects to install the payroll pack- 
age and is looking for a suitable raw material 
package. At the Wisconsin Rapids plant, they are 
happy with what the tap programs have done for 
them. | 

Vetter Manufacturing Company, of Stevens 
Point, Wisconsin, is a manufacturer of window 
frames and sashes. The company employs about 
240 people. 

The company began to investigate new ways to 
perform their data processing in the spring of 
1976. They selected the System 32 and the pay- 
roll portion of the manufacturing management 
accounting system 1ap. The computer and the 
programs were delivered in the first week of Sep- 
tember, payroll record data was entered—and less 
than two weeks after installation, the first payroll 
was run. 

The IBM system engineer had helped to make 
this conversion go smoothly. During the six 
months before delivery, he stopped by an average 
of about twice a month, to check on progress and 
answer questions. After the equipment was deliv- 
ered, he stopped by once a week for an hour or so. 
When the payroll was first run, he was at the site 
all of the day. Since that time, he has stopped by 
for a few minutes whenever he was in the area, to 
make sure that things were going all right. 

One very minor program change was needed in 
the rap—to delete a dollar amount from one re- 
port. The system engineer did this. 

It appears that raps will not meet the require- 
ments for the rest of Vetter’s applications. So one 
person is learning RPG 11 programming, for writ- 
ing programs for the other applications. 

Cheez Co., Inc., of Wisconsin Rapids, Wisc., is a 
manufacturer of cheese products. The company 
employs about 125 people. 

During the summer of 1976, the company in- 
vestigated several alternative data processing sys- 
tems. At the time, they were using a service 
bureau for their payroll and the rest of their work 


was done manually. They selected the IBM 


System 32 with 1ap general ledger and payroll 
packages. 
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The computer and the packages arrived in the 
middle of September. The general ledger pack- 
age was installed first—and the September month- 
end general ledger reports were produced on the 
system! By the middle of October, parallel payroll 
runs commenced and cutover to the new payroll 
system occurred in mid-November. 

When we talked to Cheez Co., they had not yet 
decided whether to use the 1ap accounts receiv- 
able and accounts payable packages. The data 
processing manager had had some rec 11 training 
and anticipated having to do some programming 
if suitable packages could not be found. 

Figi-Wilson Giftware Corporation, of San 
Diego, California, is an assembler and supplier of 
wholesale giftware, wall decorations, and plastic 
checkbook covers. The company employs an av- 
erage of about 25 people. , 

In the summer of 1976, Figi-Wilson started 
looking for an in-house data processing capabil- 
ity. At the time, accounts receivable was done at a 
service bureau and other processing was done 
manually. They selected the IBM System 32, with 
the manufacturing 14P including the bill of mate- 
rial processor. 

The decision was made in the middle of August 
and the computer was delivered in the middle of 
September. During this interim, an employee 
used an IBM 3741 (at IBM) to enter file data on 
diskettes, so that the files were converted by the 
time the computer arrived. 

One small change was required in the bill of 
material package, concerning the way that in- 
ventory was valued. This change was made by 
IBM at extra charge. 

By the first of November, the bill of material 
processing had been converted and was in oper- 
ation. During November, conversion of order en- 
try, inventory control, and accounts receivable 
occurred, with cutover on December 1. Next fol- 
lowed the accounts payable package. Figi- Wilson 
is still considering the general ledger and payroll 
packages. 

The company has no programming capability 
and they have no plans to acquire this capability. 


ASK Computer Services, Inc. 


The ManMAN manufacturing management sys- 
tem is a product of ASK Computer Services, Inc., 
of Los Altos, California. MANMAN consists of six 
interacting modules for inventory control, bill of 


material processing, material requirements plan- 
ning, purchasing, work-in-process, and product 
costing. The system is an on-line, interactive, 
multi-user system designed for use with a Hew- 
lett-Packard mini-computer. 

Hughes Aircraft Company, Industrial Products 
Division, is located in Carlsbad, California. The 
division manufactures image and display devices 
and systems, industrial automation systems, and 
other electronic and laser equipment. There are 
about 500 people employed in the Carlsbad 
plant. The parent company, Hughes Aircraft 
Company, with headquarters in Los Angeles, Cal- 
ifornia, has annual sales of over $1 billion. The 
company’s main data processing facilities are in 
Fullerton, California, about 50 miles north of 
Carlsbad. 

In late 1974, a data processing manager was 
named for the Industrial Products Division. His 
main assignment was to determine how mecha- 
nized production control services might best be 
provided for the division. At the time, the com- 
pany’s data processing center in Fullerton was 
providing only payroll processing for the divi- 
sion—plus, of course, incorporating division fi- 
nancial figures in the company’s financial reports. 
But local data processing needs were growing, 
particularly the need for a mechanized produc- 
tion control system. 

The data processing manager had had expe- 
rience with batch-type production control sys- 
tems and hoped, if at all possible, to avoid this 
type of system. The delays involved in batch-type 
data processing, plus the difficulties that batch 
systems have in handling complex bills of mate- 
rial, argued for the on-line type of system, he felt. 
On the other hand, the development costs for a 
custom-made on-line system might be prohibi- 
tive. So he started looking for a packaged system. 

In early 1975, he heard about ASK. After in- 
vestigating the ASK package and the Hewlett- 
Packard equipment, he recommended that they 
be obtained. An order was placed in July 1975. At 
the time the order was placed, some customized 
changes were ordered for the package. The cost 
of these changes amounted to less than one-tenth 
the purchase price of the package. 

Delivery of the equipment and package were 
delayed until the division had moved into a new 
building, in January 1976. The equipment was in- 
stalled in February. The first few weeks were used 
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for training purposes, because production per- 
sonnel were still adjusting to the new production 
facilities. Cutover to the new production control 
system occurred in early March. 

As mentioned above, MANMAN modules in- 
clude bill of material processing, material 
requirements planning, inventory control, 
purchasing, work in process control, management 
reporting, and product costing. The division has 
five very different product lines, primarily the as- 
sembly of electronic and mechanical units; essen- 
tially no fabrication is done. The MANMAN 
modules fitted the needs of these five diverse lines 
with equal facility. 

The Manan system was largely debugged by 
the time the division received it. When errors 
were encountered, the data processing manager 
would call ASK and describe the problem. ASK 
either determined the cause from the documenta- 
tion or from recreating the problem on their com- 
puter. They then changed the source code, 
recompiled the program, took the tape to a 
nearby airport and shipped it to San Diego. A di- 
vision representative would pick up the tape at 
the San Diego airport about one hour later. 

ASK is in the process of developing a financial 
package for the division, to go along with the pro- 
duction control package. 

The equipment configuration used by the divi- 
sion consists of a Hewlett-Packard 21mx with 32K 
words of memory, tape drive, two 15M byte disk 
units, a 200 |pm printer, four crT terminals and 
two terminal printers. The terminals are located 
in the stockroom, receiving, production control, 
and purchasing departments. The people who en- 
ter the data do so as part of their regular work as- 
signments and are charged with the accuracy of 
the input data. The division has no programmers 
and no computer operators—just the data process- 
ing manager and an assistant. Another benefit is 
that the computer equipment requires only about 
one-quarter the floor space that a small, batch- 
type computer with associated peripheral equip- 
ment would have required. Further, the division 
obtains program maintenance services from ASK 
at a fraction of what the salary of one program- 
mer would be. 

As is typically the case when using a successful 
generalized system, Hughes Industrial Products 
Division has no desire to add programmers or 
analysts to its staff. 


Xerox Computer Services 


Xerox Computer Services, a division of the 
Xerox Corporation, is a commercial time sharing 
service with headquarters in Los Angeles, Cali- 
fornia. XCS has developed a series of proprietary 
application systems that are available over their 
time sharing network. One of these application 
systems is a comprehensive manufacturing man- 
agement system. 


Amsco-Hall Surgical Company, located in 


Santa Barbara, California, is a division of the 
American Sterilizer Co. of Erie, Pennsylvania. 
The parent company has annual sales of over 
$140 million and employs over 3600 people. Its 
main data processing center is in Erie. Amsco- 
Hall designs and assembles pneumatic surgical 
cutting tools for orthopedic surgery. It currently 
employs about 65 people, and the business is 
growing rapidly. 

In late 1975, essentially all of Amsco-Hall’s 
data processing was being done manually. The in- 
ventory control application was the only one 
mechanized; it was being done at a local service 
bureau. But with the company’s rapid growth 
(about 40% per year), management felt that 
further mechanization of data processing was 
necessary. 

A new director of operations joined the com- 
pany about that time. He had had experience 
with Xerox Computer Services during previous 
employment and felt that XCS might provide the 
needed processing services. XCS was called in to 
look at the operation, tell what could be done, 
and estimate the costs. 

The XCS proposal looked attractive and in 
September 1975, management decided to go 
ahead with the service. One X1340 terminal was 
installed in December; this is a Diablo “daisy” 
printer with a keyboard, with a normal print 
speed of 30 characters per second. 

Management decided to convert financial ap- 
plications first, so as to be able to operate for all of 
1976 under the new financial systems. The gen- 
eral ledger application was converted first, fol- 
lowed by the accounts payable application. Both 
of these were installed in about two weeks after 
the terminal had been installed. But by the middle 
of December, the director of operations and the 
controller became concerned. The systems were 
working fine. But Amsco-Hall had decided to use 
so many of the optional features of the systems 
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that the processing load (and eventually the costs) 
was rising faster than original estimates. They 
could see that when all applications had been 
converted, the costs would be almost double the 
original estimates. So they called a halt to further 
conversions. 

Asa next step, these two executives held a two- 
day meeting with XCS representatives in early 
1976. This was a “design to cost” meeting, we 
were told. Each application was explored to de- 
termine just what options Amsco-Hall had to 
have in order to operate. Costs were estimated 
and compared to original cost estimates. It was 
recognized, of course, the increases in transaction 
volume would increase processing costs. What 
Amsco-Hall wanted to do was to come up with a 
no-frills system with which they could operate. 
Later, when management approved, some of the 
other desirable options could be added. 

In addition to reducing costs, the no-frills sys- 
tems had other advantages, we were told. It was 
easier to train people in their use and it was easier 
to make procedural revisions. 

With this new plan approved, progress was 
rapid. Some of the optional features were elimi- 
nated from the general ledger and accounts pay- 
able programs they were using. About three 
weeks later, order entry, accounts receivable, and 
finished goods inventory control were converted. 
A month later, bill of material processing was in- 
stalled, followed by piece part inventory control. 
Amsco-Hall follows the philosophy of no parallel 
operations. They convert to the new system; if it 
does not work properly, they concentrate on 
making it work and do not fall back on an old 
system. 

When we talked to them, Amsco-Hall was op- 
erating according to the “design to cost” plan and 
they were happy with the results. Any cost in- 
creases were due to transaction volume increases, 
because of the company’s growing business. They 
were just beginning to add some of the optional 
featues that management decided it wanted but 
which had been eliminated during the “design to 
cost” meeting. 

Amsco-Hall had no custom programming per- 
formed, has no programmers on its staff, and does 
not want any. They see changes they would like 
XCS to make but the changes are not crucial. The 
XCS systems appear to meet all of their data 
processing needs for the foreseeable future. 


Observations about generalized packages 


From these experiences, it seems clear to us 
that generalized application packages can pro- 
vide very satisfactory data processing services for 
organizational units in the 25 to 500 employee 
size range. A given company may find that avail- 
able generalized packages meet none of its needs, 
or only part of its needs. We would expect that, as 
time goes on, the coverage offered by generalized 
packages will be greater and greater. 

Let us reemphasize a point. None of the organi- 
zations discussed above wanted programmers on 
their staffs. In a few instances, the companies felt 
that they would have to have a programming ca- 
pability because the available generalized pack- 
ages did not meet their full needs. If the 
generalized packages could do their whole jobs, 
that is the solution they would prefer. 

A flexible retrieval and reporting system also 
goes a long way toward avoiding the need for in- 
house programming capability. With an end-user 
retrieval system, queries, ad hoc reports, and pro- 
duction reports can be created—all with no pro- 
gramming training. 

There is a major difference of opinion among 
the suppliers of small business computers on how 
best to supply application programs. On one hand 
is the truly generalized application systems which 
can do a fine job but are difficult and expensive to 
develop. Where they can be used, fine; where 
they cannot be used, the customer is encouraged 
to develop in-house programming capability. The 
other approach says that it is more efficient to 
have the application programs developed for 
each user on a custom basis by firms that special- 
ize in this type of work. 

We will now consider some experiences with 
the custom programming approach. 


Custom application software 


With this approach, the application systems 
must be developed specifically for the customer 
by the hardware supplier, by an independent soft- 
ware firm, or by a turnkey system firm. The soft- 
ware supplier may have developed master 
application programs which are then tailored to 
meet the needs of particular customers. 

It takes somewhat longer to install an appli- 
cation system and get it running with this ap- 
proach, as compared with the generalized system 
approach, because of the development time and 
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debugging time involved. Even so, the systems 
can go in quite quickly. 

As representative of this approach, we talked 
to three Basic/Four users and one Digital Equip- 
ment Corp. user. 


BASIC/FOUR Corporation 


Goodwin Handling Equipment Co., of Crystal 
Lake, Illinois, is located some 45 miles northwest 
of Chicago. The company does sales and service 
of narrow aisle fork lift trucks. It employs about 
15 people. 

In late 1973, Goodwin was using a commercial 
time sharing service for its inventory control and 
billing functions. But costs were high relative to 
the amount of work done and the company 
wanted to add several other financial appli- 
cations. So they looked at in-house small com- 
puter systems and, in early 1974, selected Basic/ 
Four. 

The Basic/Four Corporation representatives 
suggested the names of several independent soft- 
ware firms to Goodwin, for doing the applications 
programming. One was selected—and that choice 
proved to be unfortunate. The programs that 
were delivered were not satisfactory. The pro- 
grams would operate but were plagued with bugs, 
disappearing records, overflowing disk space, and 
so on. Further, the software firm had not seemed 
to grasp the essentials of the business. Goodwin 
continued to use these programs for about one 
year before finally deciding that something dras- 
tic had to be done. Basic/Four programmers at- 
tempted to fix up the programs but to no avail. 

So in late 1975, Goodwin contacted another in- 
dependent software firm in the Chicago area. This 
experience was completely different from the 
first one. Goodwin found that the people at this 
firm could “talk our language” and quickly 
grasped the essentials of the business. A complete 
new set of programs was produced in about two 
months. While some debugging was needed, the 
programs in general worked excellently from the 
outset. A few enhancements were made during © 
1976 and Goodwin now feels that they have what 
they need for the next several years at least. 

Goodwin’s remote location is not a problem ei- 
ther with the hardware or the software. Software 
problems are, in most cases, corrected by a tele- 
phone call to the software firm. For the few hard- 
ware problems that have arisen, the service 


representative generally arrives within a few 
hours of their call. 

The computer is operated by the parts man- 
ager, as a part of his job. He has learned the sys- 
tem and can make the program changes specified 
by the software firm. Goodwin has no in-house 
programming capability and has no plans to add 
it. 

Sav-On Food Co., Inc., in Santa Ana, Califor- 
nia, is a part of the Jim Bolton Group of com- 
panies. This group performs food manufacture 
and distribution of such food types as sausage, 
pepperoni, and macaroni plus corrugated boxes 
for handling the foods. They are also brokers for 
food products of other companies. Sav-On is the 
parent company of four companies of the group 
located in Southern California. Other companies 
of the group are in the San Francisco bay area, 
plus one company in Hawaii. Total sales of the 14 
companies is about $20 million per year. 

Sav-On, as the parent of the Southern Califor- 
nia companies, has been performing the data 
processing for those companies. In 1974, the com- 
pany converted from manual systems to a batch 
service bureau for accounting applications. The 
variety of companies made the requirements rea- 
sonably complex. 

By early 1975, Bolton saw the need for a faster 
response in the data processing function. He in- 
vestigated several small, interactive systems and 
selected Basic/Four. Basic/Four suggested sev- 
eral independent software firms for producing the 
application programs. Bolton talked to several 
and selected one on the basis that “we felt com- 
fortable with them.” No application packages 
were found to be suitable, but the software firm 
had had extensive experience with comparable 
application systems. 

The computer was delivered 43 days after the 
order was signed, along with the first application 
package. That application, invoicing, was con- 
verted about one week later. In less than four 
months after the computer was delivered, all 
eleven application systems had been installed— 
covering not only the Southern California com- 
panies of Bolton's group but also the Bay Area 
companies. The programs did have to be de- 
bugged and the software firm had people on site 
when new programs were being installed. After 
the initial debugging, most problems have been 
solved by telephone calls and have been fixed 
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within one hour. 

Bolton liked the system so well that in mid- 
1976, he purchased the smallest Basic/Four sys- 
tem, copied the programs, and took both over to 
his Hawaiian company. Bolton himself installed 
the applications in that company in five working 
days. Sorbus, Inc., which handles maintenance for 
Basic/Four equipment, did the machine in- 
stallation. At the time, it was the only Basic/Four 
computer in Hawaii. 

That experience was so successful that Bolton is 
considering doing the same thing for the Bay Area 
companies. | 

The company has no in-house programming 
capability and no desire to acquire any. A flexible 
retrieval system allows them to answer queries, 
prepare ad hoc reports, and even production 
reports. 

Lighting Distributors Inc., located in Irvine, 
California, is a wholesale distributor of lighting 
fixtures and equipment. Annual sales are in excess 
of $1 million and the company employs 15 
people. 

The company was formed in 1971 and has 
grown rapidly since that time. All data processing 
was done manually, but in late 1975, management 
started looking at mechanized methods. At first, 
bookkeeping-type machines were investigated. 
But it was found that, for a little more money, a 
computer system could be obtained. After look- 
ing at several systems, the Basic/Four system was 
selected in the spring of 1976. 

Basic/Four Corporation gave the company the 
names of several independent software firms. 
Management liked the first company they talked 
to because “they could talk our language.” The 
equipment was delivered 60 days after the order 
was placed and the first application (payroll) was 
run a few days later. This was the only application 
for which a package could be used; the others 
were custom programmed. During the next 
month, data files were built for the other appli- 
cations. By the end of that time, order entry, in- 
ventory control, accounts receivable, accounts 
payable, and general ledger were also running. 

There were some debugging problems during 
the early days. At the outset, a representative of 


_ the software firm came to the site and might have 


to spend two to three hours there. Within a few 
weeks, such visits were unnecessary and problems 
could be handled over the phone. Within four 


months, program bugs ceased to be a problem. 

The company has no in-house programming 
capability and has no plans to acquire it. One per- 
son handles the computer operations function as a 
part of other office duties. 


Digital Equipment Corporation 

Johnson Printers, located in Downers Grove, II- 
linois, a suburb of Chicago, does commercial job 
shop printing. The company has 75 full-time and 
10 part-time employees. 

In early 1975, Johnson Printers began to in- 
vestigate various alternatives for their data proc- 
essing. Previously they had used a service bureau 
and in early 1974 had installed a small business 
computer. But the computer had not worked out 
well for them. The capacity of the system turned 
out to be quite a bit less than the company had 


been led to expect. There were frequent hard-_ 


ware failures that gradually increased in severity. 
Finally, the system was down for 2% weeks in 
early 1976 and this triggered the decision to look 
for alternative systems with greater reliability 
and room for expansion. 

The equipment that Johnson Printers selected 
was the Digital Equipment PDP-11/40. At the 
same time they made this decision, the company 
also decided that they would develop an in- 
tegrated accounting system. In the new system, 
the data entry on a new job would start the proc- 
ess for setting up all records for that job through 
to the financial statements. The applications 
would not be stand-alone but rather would be tied 
together. 

DEC recommended the names of several soft- 
ware firms to Johnson Printers. Several were in- 
terviewed and one was selected on the basis that 
“they could talk our language.” 

The computer was installed in December 1975. 
Since that time, the reliability of the equipment 
has been excellent, one of the objectives that 
Johnson Printers was seeking. 

Because of the integrated nature of the appli- 
cations, no packaged programs could be used. An 
attempt was made to use an accounts payable 
package but it was found that a substantial num- 
ber of changes would have to be made. The sys- 
tem incorporates not only job costing (which is 
very important to printers) but also customer his- 
tory. Summary information is kept on all jobs for 
each customer for the past four years. 
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Again, because of the integrated nature of the 
system, progress has been slower than if stand- 
alone applications had been developed. When we 
talked to them, job status, job costing, customer 
history, accounts payable, and part of the payroll 
program had been developed, tied into the in- 
tegrated system, and were running, 

When program bugs have occurred, Johnson 
Printers calls the software house. The software 
firm connects their computer to Johnson’s by 
means of data communications, analyzes the 
trouble, makes a quick fix in the source program, 
recompiles, transfers the new program to John- 
son, and turns control back to the Johnson com- 
puter. Bugs are therefore corrected in very short 
order. Johnson periodically dumps their pro- 
grams to tape, with suitable backup, thus captur- 
ing such changes. 

Johnson Printers does not have in-house pro- 
gramming capability and does not desire to have 
it. All programming and maintenance are han- 


dled by the software firm. 


Observations about custom programming 


These examples illustrate, we believe, that cus- 
tom programming of the application systems is 
not an overly expensive or time consuming ap- 
proach for small organizational units. We have 
not quoted the prices paid for the software be- 
cause figures depend upon each specific case so 
much. However, each of the companies felt that it 
had paid a reasonable price for the software. 

It is interesting to note, too, that custom pro- 
grammed application packages were available in 
some of the cases just as soon as the computers 
were delivered. 

Successful application programming seems to 
be very much a function of the ability of the soft- | 
ware firm to communicate with the customer and 
to understand the customer's business problems. 
If the software firm can do these things, has had 
experience with similar applications, and can re- 
fer the customer to other satisfied clients (prefer- 
ably in the same or similar line of business), the 
chances of success would seem to be good. 

The custom programming approach may have 
one advantage over the generalized system ap- 
proach for smaller units of big companies. That 
advantage is that the systems might be designed 
using the parent company’s data definitions. Con- 
ceivably other standards might also be used, thus 


reducing the “out of control” fears of corporate 
data processing executives. 


What about turnkey systems? 


Turnkey systems are generally assembled by a 
software firm. The hardware may be selected 
from one, or from more than one, equipment 
manufacturer. For instance, the cpu may come 
from one company, the disk storage from another, 
CRT terminals from another, and so on. The turn- 
key company develops the software for a particu- 
lar application and sells the hardware/software/ 
support as a package. 

While we have talked to some users of turnkey 
systems, we have not included these cases in this 
report. One reason is that the situations are very 
similar to the cases already discussed. If the hard- 
ware/software meets the user's needs without 
change, then the situation is like the generalized 
package approach. If the turnkey supplier must 
modify the software, or even develop it from 
scratch, for the user, then the situation is like the 
custom software case. 

There are some additional problems, however. 
If the turnkey supplier selects hardware from sev- 
eral manufacturers, the problem of responsibility 
in hardware maintenance arises. Finger pointing 
at another supplier is typical in such situations. 
The turnkey supplier may have a satisfactory so- 
lution for this problem, but at least that fact 
should be ascertained. 

The turnkey system approach is based on the 
premise that the combination of hardware and 
software will be satisfactory for the user. If the 
user really just likes one of the two, then the cus- 
tom programming approach might be preferable. 

We encountered reluctance on the part of the 
hardware suppliers to recommend turnkey sys- 
tem suppliers. One reason for this, of course, is 
that the field sales force of the hardware supplier 
feels that it is in competition with the turnkey 
firms. The sales force clearly would prefer to sell 
the hardware to the user and then recommend 
two or more software firms for doing the pro- 
gramming. Another reason is, we gather, that if 
the turnkey firms get into trouble—financially, 
poor quality software, or other—then the field 
sales forces are called upon to help clean up the 
situations. 

But we have talked to satisfied users of turnkey 
systems. This is a valid approach for providing 
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computer services for the small site. There are ca- 
pable turnkey suppliers and there are marginal 
ones. The user must pay as much attention to se- 
lecting a turnkey supplier as to selecting, say, a 
computer system and an independent software 
firm. 


No in-house programming: is it valid? 

We have emphasized the point that most of the 
companies we talked to do not have an in-house 
programming capability and do not desire to have 
it. This is a rather significant point. One of the 
chief objections by corporate data processing 
management to the types of services we have dis- 
cussed in this report is that “‘pretty soon each site 
will build up a programming and operating staff.” 
So the question needs to be raised: is our point a 
valid one? 

In support of the validity, it is a matter of fact 
that most of the sites we talked to do not have in- 
house programming capability and most told us 
emphatically that they did not want it. Such ca- 
pability was being considered only by users of 
some generalized packages where they could not 
find additional packages to meet their needs. In all 
cases where the user could get all desired pro- 
grams from outside sources, no in-house capabil- 
ity was considered. 

On the other hand, none of the companies we 
talked to had been using their computer services 
very long—generally, only a year or two. Will 
management feel the same way about in-house 
programming in, say, five years? 

We think the answer lies in the availability of 
flexible, user-oriented retrieval packages. If the 
non-programmer user can quickly learn to re- 
trieve, manipulate, display, and print data—for 
answering queries, for ad hoc reports, and for new 
production reports—this answers most of the 
needs for in-house programming. The program- 
ming of the data validation and file update func- 
tions can then be purchased on the outside. 

Only time will tell if these companies will want 
an in-house programming capability. Our opinion 
is that the methods they are now using are work- 
ing well enough that the companies will continue 
their present policies. 


If you seek generalized packages 


Generalized packages have a lot to offer. They 
are relatively quick and easy to install. Often, the 
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user finds that there is no debugging period. 
Maintenance is performed by the supplier, if bugs 
are found. If truly generalized, the user has to 
make only minor changes in procedures in order 
to adapt to the use of a package. 

On the negative side, the user is at the mercy of 
the supplier as far as enhancements and addi- 
tional packages are concerned. The generalized 
packages may perform only a part of the overall 
job that the user wants done. 

There is no reason why the user could not turn 
to independent software firms for enhancements 
and additional applications. But the generalized 
package supplier does not encourage this, we 
gather—and, in fact, might push the user in the di- 
rection of in-house programming. 

If a large organization has a number of small 
sites that want their own computer services, then 
generalized packages would promote consistency 
and standardization. 


Costs of generalized packages 


One of the sales claims for generalized pack- 
ages is that the cost to the user will be less than for 
custom programming. This is not necessarily true. 
Let us briefly consider the three main ways of 
paying for generalized packages. 

Outright sale and maintenance charge. The 
supplier may offer the package for a fixed price 
plus an annual charge for maintenance. But the 
price of the package might be about what a cus- 
tom programmed system could cost. Why? Be- 
cause the cost of developing a truly generalized 
package is substantially more than the cost of a 
custom system. Add to this the cost of marketing 
the package and conducting the business and a 
non-trivial price results. It is quite possible, of 
course, that the generalized package might be 
better designed and documented. 

Installation charge and monthly lease. At first, 
this looks like it would be a much less expensive 
approach than custom programming. But if the 
lease terms are “from here to eternity,” then the 
amount paid to the supplier in, say, four years 
might well exceed the cost of custom program- 
ming. Some suppliers offer “paid up” leases, 
where lease payments cease after two or three 
years. This would seem to be a much more attrac- 
tive arrangement for the user. 

Usage charge on commercial time sharing sys- 
tem. This approach requires the least investment 
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by the user. But once again, the charges are con- 
tinually imposed, month after month. Moreover, 
the charges might vary linearly with volume. 
Counting volume growth and continuing usage 
charges, this approach might also cost more in 
four years than would custom programming. 

Generalized packages might be attractive eco- 
nomically. But to really determine this, look at to- 
tal costs over at least a four to five year time 
period. 


Selecting and installing a generalized system 


Just because a package is generalized does not 
mean that it is right for any particular company. 
What the package does and what it requires of the 
user must be carefully investigated. Get a precise 
definition of all input requirements—what data 
fields, what time schedules, what turnaround of 
corrections for detected errors? Get a precise def- 
inition of all outputs produced by the system— 
how well can they replace existing reports and 
documents, how will queries be answered, how 
will ad hoc reports be produced? Examine the de- 
cision rules used by the system (for example, the 
method of aging accounts receivable balances). 
What help will the supplier provide in prepara- 
tion for and in making the installation? How un- 
derstandable is the package operating 
instructions for the user? What adjustments in 
company procedures will be needed in order to 
use the package? What custom programming will 
the supplier do to fit the package to the user’s 
needs? 

Having found a suitable generalized package, 
the user should make one person at the site fully 
responsible for installing the package. This per- 
son should not be a supplier representative. Fur- 
ther, the higher this person is in the management 
of the site, the better. This person should thor- 
oughly study the package installation guidelines 
and then lay out a detailed plan for making the in- 
stallation. Finally, try to avoid peak load periods 
for making the installation. 


If you prefer customized programs 


If you cannot find generalized packages for any 
or all of your data processing, then you may want 
to buy custom programming services from out- 
side—from the hardware supplier, from an inde- 
pendent software firm, or from a turnkey system 
firm. : 
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Some of the cases described in this report in- 
dicate the advantages and risks of this approach. 
On the plus side, the application systems can be 
tailored to the user’s specific needs. If the user is a 
part of a large company, then corporate standard 
data definitions and decision rules might be used. 
On the negative side, if the supplier and user do 
not communicate well, the user might end up 
with unsatisfactory programs—numerous bugs, do 
not do job quite right, do not do whole job, hard to 
change, and so on. 

One point we have heard time and again—be 
very careful about soliciting proposals for the 
programming and then taking the lowest priced 
proposal. Yes, such proposals will uncover signifi- 
cant differences in the prices. But the lowest 
priced proposals might be quite unsatisfactory. 
The suppliers may have made too superficial a 
study of the requirements, or may have misunder- 
stood them. If a supplier gets the job and then re- 
alizes it will be a money-losing one, then all sorts 
of bad things start to happen. Corners are cut, 
portions of the system eliminated, testing is re- 
duced—and the user then lives in misery with the 
results. 

If the supplier has programmed the same appli- 
cations a number of times previously for other 
companies, talk to some of those customers and 
find out how satisfied they are. 

There is another step that should be consid- 
ered, whether or not the supplier has pro- 
grammed the application(s) before. That step is to 
break the system building process into two 
phases—a specification phase and a building 
phase. For some fixed price, the supplier should 


study the requirements and develop the specifica- 


tions for the new system(s). These specifications 
should define precisely what the new system(s) 
would do—what inputs are required, what out- 
puts would be produced, what decision rules 
would be used, and so on. The supplier would also 
be in a position to give a realistic fixed price quo- 
tation for building the system(s). If the customer 
does not like what is presented, at least two op- 
tions should be provided. One, the supplier should 
correct the specifications at no extra charge until 
they meet the customer’s needs. Or two, the cus- 
tomer should pay the supplier the fixed price for 
the specifications, take the specifications, and 
give the job to another supplier. 
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The top information executive 

In recent issues, we have been discussing what 
appears to be an emerging new position—the top 
information executive within an organization. 
We have pointed out that this position might 
eventually have responsibility for the computer 
services, Communications services, clerical and 
filing services, and the other information handling 
activities within the organization. The purpose of 
creating this new position would be to try to deal 
with all of these activities in a more organized, 
more efficient manner. 

In this report, we have pointed out that it is 
now practical to provide computer services for 
small, possibly remote sites. If these sites feel that 
they cannot obtain adequate services within a 
reasonable time frame from the corporate com- 
puter department, then they will increasingly de- 
mand the right to go outside for the services. 

But why bring up the idea of a top information 
executive here, you might ask. Why isn't this 
something for the top data processing executive 
to deal with? The reason, as we see it, is that the 
small business computer for the small site opens 
the door for a variety of other services. These sites 
will become interested in word processing serv- 
ices, computer message systems, remote com- 
puting services, and so on. These services do start 
to get beyond the jurisdiction of the top data 
processing executive, we suspect. 

The recent announcements of the IBM Series 1 
and the Univac BC/7 small business computers 
are of interest here. IBM’s marketing strategy for 
the Series 1 appears to support the concept of 
central control of data processing. The Series 1 
has a very limited software support at present. 
IBM seems to be saying that if the small organiza- 
tional unit of the large company wants a Series 1, 
it should get it through corporate headquarters 
and have the corporate computer department do 
the programming. The BC/7, on the other hand, 
seems to be aimed at small, first-time users of 
computers. More software support is provided, 
with particular emphasis at the outset on whole- 
sale distribution and manufacturing applications. 

With either system, we suspect that software 
will become available for providing word proc- 
essing services, computer message services, and 
other computer-based services on these systems. 

More and more organizational units of enter- 
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prises will be using more and more computer- 
based services. Some of these services extend 
beyond the traditional boundaries of data proc- 
essing. So the need for a top information execu- 
tive should be viewed with this development in 
mind. The use of these services in an organized, 
efficient manner deserves management’s atten- 
tion. Further, the use of these services is not in the 
distant future, it is arriving now. 
Addendum 

As we went to press, IBM made two announce- 
ments in the small business computer area. One, 
System 34 is an upgrade of the System 32. The 34 
can handle up to eight terminals and/or printers, 
has extended communications capabilities, and 
has a fixed disk storage facility of up to 27 million 
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bytes. System 32 programs and 14Ps can be run on 
System 34. 

The second announcement concerned the 
Series 1. An operating system with multi- 
programming capabilities was added. Fortran 
and pL/1 programming languages are offered (but 
COBOL is not). The only Series 1 applications soft- 
ware so far offered by IBM is for facilities man- 
agement/power management, for monitoring 
purposes. 

These announcements indicate that IBM is 
moving even more aggressively into the area of 
small business computers. Moreover, they seem to 
be in harmony with our discussions in this issue. 
Small business units are going to receive an in- 
creasing share of attention in the computer field. 
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